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STANDARD  INTERFACE 
FOR 

DATA  TRANSFER  EQUIPMENT 


1.0  SCOPE 

..  establishes  techniques  to  be  used  in  the  development  or 

modification  of  airborne  data  recorders  (ADR)  (i.e.,  turbine  engine  moni¬ 
toring  system  recorders,  aircraft  structural  recorders,  etc.)  and  their 
associated  electronic  data  transfer  units  —  called  data  collection  units 
(DCU).  It  has  been  developed  to  ensure  compatibility  of  data  transfer  devi¬ 
ces  with  a  wide  variety  of  flight  recorders  and  should  be  used  to  reduce  the 
number  of  unique  DCUs  developed  to  support  recording  devices.  This  document 
describes  data  communications  between  DCUs  and  the  associated  flight  recor¬ 
ders  and  ground  station  computers  (GSC)  or  other  flight  line  support  equip- 
iTi0  n  u  • 

2.0  APPLICABLE  DOCUMENTS 

The  following  documents,  of  the  exact  issue  shown,  form  a  part  of  this 
standard  to  the  extent  specified  herein.  In  the  event  of  conflict  between 
the  documents  referenced  herein  and  the  contents  of  this  standard,  the  con- 
tents  of  this  standard  shall  be  the  superseding  requirement. 

GOVERNMENT  STANDARDS 

MIL-STD-704D  Aircraft  Electrical  Power  Characteristics 

MIL-STD-810C  — - - 

MIL-STD-1560A 


GOVERNMENT  SPECIFICATIONS 

MIL-C-38999H  Connectors,  Electrical... 

INDUSTRY  STANDARDS 

EIA  STANDARD  RS-232C 


EIA  STANDARD  RS-363 


EIA  STANDARD  RS-422A 


3.0  REQUIREMENTS 

This  section  defines  the  requirements  for  interfacing  airborne  data 
recorders,  data  transfer  devices,  and  ground  computers  (or  other  flight  line 
support  equipment).  It  details  both  the  hardware  interface  (physical  and 
electrical  characteristics)  and  the  data  communication  protocol  (software/ 
fii^are  programmed)  necessary  for  physical  and  functional  compatibility  of 
all  the  units  mentioned  above. 


Interface  between  Data  Terminal  Equipment 
and  Data  Communication  Equipment  Employing 
Serial  Binary  Data  interchaW 
Standard  for  specifying  Signal  Quality  for 
Transmitting  and  Receiving  Data  Processing 
Terminal  Equipments  using  Serial  Data 
Transmission  at  the  'Interface  ITOi' 

Non- Synchronous  Data  Communication  Equipment 

Electrical  unaract eristics  of  Balanced - 

Voltage  Digital  interface  circuits 


mvironmencai  lest  wetnods 


hsert  Arrangements  forlTrL-C-38999  and  MIL-C-27599 


lectrical.  Circular  ConnectoH 
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3.1  Hardware  Interface  Requirements 

3.1.1  Physical  Characteristics 

This  section  details  the  physical  interface  characteristics  of  the 
DCU,  airborne  data  recorder,  and  the  ground  computer.  It  addresses  control 
devices  located  on  each  piece  of  equipment,  as  applicable,  and  displays 
since  these  are  part  of  the  equipment  interface.  Control  of  the  flight  and 
ground  equipment  using  switches  or  displays  will  be  discussed  in  detail  in 
the  following  hardware  and  software  requirements  sections. 

3. 1.1.1  Connectors 

All  connectors  applicable  to  this  interface  shall  comply  with  the 
requirements  outlined  in  MIL-C-38999H,  Connectors,  Electrical,  Circular.., 
with  the  following  additions/revisions  to  the  requirements:  ' 

a)  All  connectors  that  can  be  mated/unmated  in  a  Class  1,  Division 
1  hazardous  location,  as  defined  in  the  National  Fire  Protection  Association 
(NFPA)  National  Electrical  Code  70-1983,  shall  be  explosionproof  with  arc 
suppression.  The  explosive  atmosphere  test  shall  be  in  accordance  with 
MIL-STD-810C,  Method  511,  procedure  I. 

b)  The  durability  of  the  connector  shall  be  1000  mate/unmate  cycles 
when  tested  per  paragraph  4.7.7  of  MIL-C-38999H. 

c)  The  connector  shall  be  of  a  scoop-proof  design,  have  a  size  15 
shell  and  use  the  type  B  recommended  panel  mounting  dimensions  per 
MIL-C-38999H.  The  connector  shall  use  the  standard  19  pin  insert  arrange¬ 
ment  for  the  corresponding  shell  size,  per  MIL-STD-1560A. 

3.1 .1 .2  DCU  Controls  and  Displays 

Display 

The  DCU  shall  have  an  electro-optical  display  of  at  least  eight 
characters.  The  display  may  be  capable  of  displaying  more  ASCII  encoded 
characters  than  the  alphanumerics,  but  the  allowable  display  characters 
shall  be  limited  to  those  listed  in  Table  2.0.  The  display  shall  be  capable 
of  displaying  a  line  of  20  characters  —  if  scrolling  is  employed  to  achieve 
the  line  display,  the  character  scrolling  shall  be  manually  controlled. 

Each  logical  line  of  display  information  shall  be  ended  with  an  ASCII 
encoded  carriage  return  (CR).  The  memory  locations  associated  with  the 
display  shall  be  transparent  to  the  unit  sending  the  data  to  the  DCU. 

3. 1.1. 2. 2  Data  Transfer  Initiation 

The  DCU  shall  have  means  for  switching  the  battery  power  to  the 
interface  on  and  initiating  communications  and  data  transfer. 

3. 1.1.2 .3  BIT  Initiation 

The  DCU  shall  have  a  means  for  initiating  DCU  built-in-test  as 
required  by  the  DCU  specification  or  statement  of  work. 

3. 1.1. 2. 4  Fault  Indication 

The  DCU  shall  have  an  electro-optical  display  that  automatically 
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Oc"S*'1hl  transmuted  to  the 

if  I  fl  activated  as  soon  as  data  transfer  is  comoletPd 

If  a  fault  code  has  been  transmitted.  This  function  shall  be  transoarent^to 
the^transmitting  un,t  as  discussed  In  section  3.2.2.l.7r  Fault  InX??on 

3. 1.1.3  Cable(s) 

data,ceco?d\%1^c’; 

s!?“^rfo"j'di?r;j;Ss^::  -iio‘s^ 

•! >4  ADR/DCU  Power  Requirements 

snoc  /  h  The  DCU  shall  be  self-powered  and  capable  of  supplying  +28VDC  to 
ADRs  (when  aircraft  power  is  unavailable  to  the  ADR)  within\he  tolerances 

ent’^i1hI"i-^ioi^-^°^°*  wheiher  oJ  not  power  ?sTe- 

tnterf«f  "oi”  'rh^nn'!""”’"’''  “Etching  Its  battery  poSer  to  the 

interface  on  .  The  DCU  may  use  GSC  provided  power  to  power  itself  The 

forTwrUrSf  at^lfas*?  '«  2-0  ArapIJes 

ror  a  period  of  at  least  1  hour  before  recharging  shall  be  reouired  Anv 

ADRs  using  the  standard  interface  must  also  be  compatible  with  MIL  STD  7Q4n 

power;  and  sha  1  have  a  rated  load  of  no  greater  than  2:0  Ceres  at  SsJSf 
Within  the  tolerances  of  MIL-STD-704D.  amperes  at  +Z8VDC 

^ *3  Electrical  Characteristics 

communication  among  ^UsrAoLran^g^o^Jd^LmjSt^s?®  requirements  for  data 

3 .1 .2 .1  EIA  Standard  Interfaces 

sundard  1nI:rla«1%ortu"'c^LicrtUn"’'-! 

JIiSreitheJN«e?fMl'  the  DCU 

duplex  and  an  RS-4pA  dual-slmplex  uluac?°''?e1a ns'’o?"thruter?aJe;  and 
Sarag?IpSr°"  °  the  fonlln?sul 

3. 1.2. 1.1  RS-232C  Interface 

dards  are;  Standard  RS-232C.  Related  cross-reference  stan- 

a)  CCITT  V.24 

b)  CCITT  V.28 

c)  ISO  2110 

stanH,rHi  .Si  the/'orlmary  data"  and  "ground"  circuits  (as  defined  In  the 


3. 1.2. 1.2 


are: 


RS-422A  Interface 
Reference  EIA  Standard  RS-422. 


Related  cross-reference  standards 
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a)  CCITT  V.ll  (X.27) 

b)  FED-STD-1020 


The  RS-422  shall  be  implemented  as  described  in  the  EIA  Standard 
except  for  the  required  circuit  driving  capability.  The  implemented  inter- 
capable  of  driving  at  least  two  (2)  RS-422A  receiver  circuits. 
The  RS-422A  interface  shall  be  capable  of  satisfactory  operation  at  two  (2) 
discrete  Baud  rates  as  specified  in  paragraph  3. 1.2. 2,  Data  Rates. 

3 .1 .2 .1 .3  DCU  Polling  to  Determine  Active  Interface 
...  j  DCU  shall  initiate  communications  on  both  interfaces  as  spe¬ 

cified  in  paragraph  3.2.3.8  at  the  low  rate,  initially.  If  no  response  is 
received  on  either  low  rate  interface,  the  DCU  then  assumes  the  active 

RS-422.  If  no  response  is  received  on  the  high- 
rate  RS-422  interface,  the  DCU  shall  declare  a  communications  fault. 

Timeout  ‘^i^^“?sed  further  in  paragraphs  3. 2. 3. 7  and 

3.2.3.8,  respecpvely.  After  identifying  the  active  interface,  the  DCU 

fnH  DC  P"  interface.  The  "off"  states  for  the  RS-232 

and  RS-422  interfaces  shall  be  "spacing"  and  logic  high,  respectively. 

3.1 .2.2  Data  Rates 

The  data  rate  for  the  RS-232C  Interface  shall  be  9.6K  Baud  (on  all 
equipments).  The  DCU  RS-422  Interface  shall  have  a  high  and  a  low  data 

"Jl'shln  be  Ig!^  b°:u3!  ' 

3.1 .2.3  Signal  Quality 

for.  rilJ!  lowing  subparagraphs  outline  the  signal  quality  requirements 
for  the  data  transmission  and  reception  circuits  addressed  in  this  document. 

3. 1.2. 3.1  Trans  mi  tters 

3.1 .2.3.1 .1  Distortion 

u  u  In  the  communications  transmitter  circuits,  the  signal  provided 
shall  have  a  synchronous  start-stop  distortion  not  greater  than  1.0%,  and  a 
distortion  of  not  greater  than  2.1%,  assuming  no  signal 
element  shall  have  a  duration  of  less  than  97.9%  of  a  unit  interval. 


3. 1.2. 3. 1.2 


Character  Interval 
Under  continuous  start-stop  operation,  the  signals  provided  on 


4.u^  •  IV  uperdtion,  zne  Signals  provided  oi 

the  communications  interface  may  have  a  minimum  average  character  interval 
shorter  than  the  nominal  character  interval  and  an  occasional  character  with 
duration  (called  the  minimum  character  interval)  according 
to  the  following  definitions  (from  EIA  Standard  RS-363):  ^ 

a)  Minimum  Average  Character  Interval  -  In  continuous  start- 

interval  between  successive  start  transitions  on  the 
transmitted  data  circuit  averaged  over  2  consecutive  characters  shall  be  no 
less  than  the  nominal  character  interval  reduced  by  3%  of  a  unit  interval. 

b)  ^  Minimum  Character  Interval  -  In  continuous  start-stop 
operation,  the  interval  between  successive  start  transitions  on  the 
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JaTreJiced  bf character  inter- 
3 .1 .2 .3 .2  Receivers 

3.1.2.3.2.1  Receiving  Margin 

have  a 

3. 1.2. 3. 2. 2  Character  Interval 

a’rjc?Lf5nTT"rr  JnSjjjrand 

S?a^^SJd"Rl"3*l3T"“ 

stop  opooatlo^!  tXrirpTeSe'^tTo^J^fJe^Jf;, 

redoce^by'lwlra  oHif^e^Jal’!”  ‘'’^" 

operation  when'th^above  average'[s'met'^the'receiver(0°shan*b*'**°'’ 
to  respond  to  a  start  transition  whi“  follows  trfnM^iorof'S^ 

5ir?l"?e5”?rS!5?^f%"  :n"fnSle?v“al!“  ^-Ic^rintr- 


3. 1.2.3. 2. 3 


Minimun  Duration  Start  Element 

In  the  communication  system,  when  the  receiver  is  in  the  stoo 
condition,  it  shall  not  hp 


(nr  uaitinni  ^  tne  communication  system,  when  the  receiver  is  in  the  stoo 
(or  waiting)  condition,  it  shall  not  be  required  to  respond  to  TcharactPr 

?Sterv'a'??'"'  ^  51 -5^  of  S  unTt 


OCU  Connector  Pin  Assignments 

Electrical  signals  are  assigned  to  the  connector  pins  as  follows: 


Pin 


A 

B 

C 

D 

E 

F 

G 

H 

J 

*K 


Signal 

RESERVED  (no  connection) 

RESERVED  (no  connection) 

High  (Received  Data,  relative  to  DCU) 

+28  VDC  (Received  Data,  relative  to  DCU) 

+28  VDC  Return 

High  (Transmit  Data,  relative  to  DCU) 

relative  to  DCU) 

Discrete  Test  Return 

Closure  to  pin  J  for  data  transfer  (less  than  100  ohms) 
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L 

M 

N 

★★p 

**R 

S 

T 

U 

V 


RS-232C  Transmitted  Data  (circuit  BA)  (relative 
RS-232C  Received  Data  (circuit  BB)  (relative  to 
Signal  Ground  (circuit  AB) 

Signal  Shields 

Protective  Ground 

MIL-STD-1553B  Data  High  (optional) 

MIL-STD-1553B  Data  Low  (optional) 

RESERVED  (no  connection) 

RESERVED  (no  connection) 


to  DCU) 
DCU) 


Pin  K  must  be  connected  to  Pin  J  before  communications  are 
attempted  and  must  remain  connected  until  communications  are  complete.  This 
IS  necessary  for  data  transfer  from  ADR  to  DCU  only.  The  pins  may  be  per- 
manent  y  connected  within  the  DCU.  ADR  circuits  shall  supply  a  mLiLS  of 
20  mill! amperes  through  the  DCU  switching  circuit. 

**N0TE:  Protective  ground  shall  double  as  the  power  shield  and  shall 

at  th^^Ano/rcr  ends  of  the  DCU  cable.  Signal  shields  shall  be  grounded 
at  the  ADR/GSC  mating  end  of  the  cable.  ^ 

3 »2  Software/Protocol  Requirements 

transfer  protocol  defines  the  allowable  ASCII  character 
characters,  control  concepts,  and  machine  states.  The  control 

rShif  ? T  5^®  protocol  shall  be  limited  to  those  defined  in 

raoie  i.o.  All  display  characters  and  control  characters  shall  be 
transmitted  as  defined  in  Tables  1.0  and  2.0. 

3.2.1  Character  Set 

I^®  set  recognized  by  this  protocol  shall  be  limited  to 

those  characters  listed  in  the  complete  set  of  codes  referred  to  as  the 
American  standard  Code  for  Information  Interchange  (ASCII),  1968  (Table 

Jhn  ^nclf®  transmitted  in  fields  that  are  supplied  to 

the  display  on  the  DCU  shall  be  limited  to  those  listed  in  Table  2.0, 

3.2.2  Protocol  Format 

The  protocol  defined  herein  is  a  character  oriented  protocol.  For 
tnis  application,  asynchronous  communications  shall  be  implemented. 

3. 2. 2.1  Header  Format 

After  communications  have  been  established,  a  header  message  shall 
be  transmitted  once  for  the  entire  data  package.  The  header  shall  be  used 

functions.  Its  format  and 

Ihfii  shall  be  as  shown  in  Figure  1.0.  Individual  fields 

shall  be  encoded  as  specified  in  the  following  subparagraphs. 

3. 2. 2. 1.1  Start  of  Header  (SOH) 

See  paragraph  3. 2. 5.1  and  Table  1.0. 

3. 2. 2. 1.2  ADR  Device  Identifier 

A  w  ^ylce  identifier  field  immediately  follows  the  SOH  and  is 
follwed  by  delimiter  #1  (DCl).  It  is  a  variable  length  field  traccomodate 
varying  device  serial  numbers.  The  device  identifier  shall  designate  the 
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intended  airborne  device  for  data  upload  and  identify  the  source  of 
downloaded  data.  This  identifier  shall  also  be  used  for  data  segregation  on 
the  ground  station  computer.  The  device  identification  shall  consist  of  two 
parts  --  a  generic  identifier  and  a  specific  identifier.  The  first  three 
bytes  shall  represent  the  generic  identifier  to  be  used  when  an  upload  of 
numerous  devices  is  desired.  A  contractor  selected  3-byte  code  shall  allow 
upload  of  data  to  any  device  that  recognizes  this  code  thus  allowing  control 
of  data  configuration.  When  upload  to  one  specific  unit  is  desired,  the 
generic  Identifier  shall  contain  three  nulls.  The  specific  identifier  shall 
occupy  the  remainder  of  the  field  and  shall  contain  the  exact  serial  number 

upload  or  request  is  intended,  if  required  by  the 
particular  ADR.  The  generic  identifier  shall  have  priority  in  deciding^ 

‘^isallow  an  upload.  This  field  shall  never  contain  OCU 
or  GSC  identifier  numbers. 

3. 2.2. 1.3  Block  Count  Field 

reflect  the  number  of  blocks  to  be  transmitted  (65,535  blocks  of  256  bytes 

coimt  Hn^onki  significant  byte  shall  be  transmitted  first.  This 

count  will  enable  the  receiving  device  to  predetennine  that  sufficient 

storage  capacity  exists  before  the  text  mode  is  entered  for  data  transfer. 

3. 2. 2. 1.4  Aircraft  Tail  Number 

4.  -1  u  fi>craft  tail  number  shall  be  fixed  8-byte  field.  If  the 
tail  number  IS  less  than  8  alphanumeric  characters,  it  shall  be  filled  with 

la?l  tie  aircraft 

tail  number  is  not  available. 

3. 2. 2. 1.5  Aircraft  Type  Identifier 

^  **.4.  ^^^f.s^isll  be  a  variable  length  field  that  designates  the 

T46A,  BIB,  etc.).  The  end  of  this  field  shall  be  iden- 

thrADR^^thiVflii®^  type  is  unavailable  or  unknown  to 

the  ADR,  this  field  shall  be  absent. 

3. 2. 2. 1.6  Engine  Identifiers 

k  y®Fying  aircraft  configurations,  the  engine  identifier 

nr^f  shall  follow  DC2  and  precede  delimiter 

!ni  k"®^-®  ;<*®"tifier  shall  be  8  bytes  in  length  with  leading 

helical!  ^^®  '’4!7’*’®r  '•s  l®ss  than  8  alphanumeric  characters.  If  engine  num¬ 
bers  are  unavailable  or  not  applicable,  this  field  shall  be  absent. 

3. 2. 2. 1.7  Fault  Indication  Byte 

fioiH  chaii^JL^'*®*®"*®  Sr  (Table  2.0)  byte  within  the  fault  code 

.nf  ThI  ??  transmitted  from 

the  ADR.  The  GSC  shall  place  an  ASCII  coded  "!"  in  this  field  when  Ini- 

tiaiizing  the  DCU  with  upload  or  function  request  data.  This  ’*!"  is  used 

only  by  the  DCU  to  recognize  that  it  has  been  initialized  by  a  GSC.  The 

with^an^AD^*^^  removed  by  the  DCU  prior  to  initiation  of  communications 
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3»2*2«1«8  Fdult  Cod6  Display  Fi6ld 

This  shall  be  of  variable  length.  It  shall  follow  the  fault 
indication  byte  and  precede  pC4.  Any  information  transmitted  in  this  field 
shall  be  available  for  OCU  display  and  shall  also  be  transmitted  in  the 
transparent  data  field.  If  no  fault  codes  were  logged  by  the  ADR  this 
field  shall  be  absent. 


3. 2. 2. 1.9  Additional  Data  Field 

The  additional  data  field  shall  be  used  for  different  purposes 
depending  upon  the  equipment  connected  and  direction  of  data  transfer 
For  data  download  (i.e.  ADR  to  DCU  to  GSC)  this  field  shall  contain  data 
that  needs  to  be  accessed  at  the  flight  line  or  in  the  absence  of  a  GSC. 

Any  data  transmitted  within  this  field  (during  a  download)  shall  be 
available  for  display  by  the  DCU  and  shall  also  be  transmitted  in  the 
transparent  text  data  blocks  as  required  by  each  application. 

<haii  ^  field  during  a  DCU  to  ADR  header  transmission 

^  ®  upload  (i.e.  GSC  to  DCU  to  ADR,  or  DCU 

to  ADR)  IS  commanded. 

The  presence  of  this  field  during  a  DCU  to  ADR  header 

transmission  shall  convey  to  the  ADR  that  an  application  unique  function  is 
commanded. 

The  additional  data  field  shall  be  followed  by  delimiter  #  5 

\  I  b  /  • 


3.2.2.1.10 


3.2.2.1.11 


End  of  Text  (ETX) 

See  paragraph  3. 2. 5. 4  and  Table  1.0. 


_ _  Block  Check  Character  (BCC) 

The  BCC  is  the  result  of  a  Longitudinal  Redundancy  Check  (LRC) 
and  shall  be  appended  to  the  end  of  the  transmission.  This  calculation 
shall  be  bounded  by  the  start  of  block  (SOH/STX)  and  end  of  block  (ETB/ETX) 
exclusively.  The  BCC  functions  as  a  message  content  error  detection  scheme. 
An  LRC  IS  defined  as  a  parity  on  columns.  Column  parity  shall  be  odd.  For 
example,  an  odd  column  parity  generates  the  following  BCC. 


BYTE 


10110010 

01101001 

11011001 


BCC=11111101 

•n  -4.  the  current  BCC  with  the  next  byte 

will  maintain  a  BCC  of  even  parity.  Complementing  the  final  BCC  will  pro¬ 
vide  an  odd  parity  BCC.  This  calculated  BCC  shall  be  appended  to  the 
transmission  or  used  for  comparison  with  the  received  BCC.  This  approach  is 
illustrated  below. 


Byte  1  11001101 

©  Byte  2  10011011 

01010110 


8- 


©Byte  3  01101100 

OOl 11010 

Complement  11000101  =  BCC 


3  »2 .2  »2  Data  Transfer  Format 

After  communications  have  been 
data  has  been  received,  the  transfer  of 
data  format  as  shown  in  Figure  2.0. 


established  and  documentary  (header) 
data  shall  be  accomplished  using  the 


3»2. 2.2.1  Start  of  Text  (STX) 

See  paragraph  3. 2. 5. 2  and  Table  1.0. 

3. 2. 2. 2. 2  Data  Byte  Count 

or  locci  An  8-bit  numerical  value  defining  the  data  block  size  (256  bvtes 

detection  of  data  transparency  and  assist 

aetection  or  transmission  errors.  Zero  shall  reDre<;pnt  if  a 

data  to  send,  the  block  count  (see  3.2.2a?]!  wtute  equate  ae^To)!’  ^ 

3. 2. 2. 2. 3  Transparent  Data  Field 

tion  itsel/^^Thrfl?o^^U  data  which  is  peculiar  to  the  applica- 

be  a  fJnction  J5®.;"^®'TJretation  and/or  processing  of  this  information  shall 
De  a  functioii  of  the  particular  device  for  which  it  is  intended  fi  e 
acquisition  device  or  ground  computer).  *  ** 


3. 2. 2. 2.4  End  of  Block  (ETB) 

See  paragraph  3. 2. 5. 3  and  Table  1.0. 

3 ♦2.2.5  End  of  Text  (ETX) 

See  paragraph  3. 2. 5. 4  and  Table  1.0. 

3.2. 2.2 .6  Block  Check  Character  (BCC) 

See  paragraph  3.2.2.1.11. 


3 »2 .3  Protocol  Considerations 

subparag?ajhs?^  implementation  considerations  are  discussed  in  the  following 


3.2 .3.1  Framing  Control 

defined  as  the  detemi nation  of  which  eight  bit  qrouos 
llTl  bil  Sjjrrr/"'*  f  Characters  coustltelrnKs^g^sT 

te  r:  gnif?c"aS  ‘’b?r!?^s5*‘  i  te\?,"iitted 

teuS  contractor  tor  each  peculteC  MR'appllM- 

to.  The  following  information  shall  be  transmitted  ASCII  encoded: 


a) 

b) 

c) 

d) 

e) 

f) 


All  control  characters  (per  Table  1.0) 

ADR  identifier  number 
Aircraft  tail  number 
Aircraft  type 
Engine  identifier(s) 

Fault  and  additional  data  display  information 
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The  following  Information  shall  be  transmitted  non-ASCII  encoded: 

a)  Block  count  (two  bytes) 

b)  Block  check  character 

c)  Data  byte  count 

3. 2. 3. 2  Error  Control 

Error  detection  shall  consist  of  hardware  detected  parity  error  on 
all  bytes,  erroneous  LRC  value,  and  transmission  related  problems  (i.e. 
loss  of  communications,  etc.).  ’ 

3. 2. 3. 2.1  Byte  Parity  Error 

A  byte  parity  error  detected  during  the  reception  of  a  header  or 
text  block  shall  result  in  a  receiver  request  for  retransmission  (NAK)  after 
the  block  transmission  has  terminated.  Such  an  error  detected  during  the 
reception  of  single  control  characters  (for  handshaking)  shall  generate  a 
negative  acknowledgement  (NAK)  resulting  in  the  retransmission  of  the 
control  character.  Five  (5)  retransmission  attempts  shall  be  made  before 
declaring  a  communications  fault. 

3. 2. 3. 2. 2  LRC  Error 

An  erroneous  LRC  value  in  the  BCC  shall  generate  a  negative 
acknowledgement  (NAK)  response  by  the  receiver.  The  transmitter  shall  make 
five  (5)  attempts  to  retransmit  the  same  block  before  declaring  a  communica¬ 
tions  fault. 

3. 2. 3. 3  Sequence  Control 

Since  communications  used  in  this  interface  are  half-duplex, 
message  numbering  is  not  required.  A  positive  acknowledgement  control 
character  shall  be  sent  in  response  to  correctly  received  control  characters 
and  data  blocks  as  illustrated  in  the  functional  flowcharts.  The  affir¬ 
mative  acknowledgement  control  character  shall  be  transmitted  as  the  ASCII 
code  for  ACK.  The  reverse  interrupt  control  character  is  an  affirmative 
acknowledgement  transmitted  as  the  ASCII  code  for  RVI.  The  ACK  and  RVI 
characters  maintain  transmission  sequence  and  establish  the  line  direction. 

3. 2. 3. 4  Transparency 

Transparency  of  application  unique  data  is  imperative  to  avoid 
interpretation  of  data  as  control  characters.  Transparency  shall  be 
achieved  by  the  data  byte  count  technique. 

3. 2. 3. 5  Line  Control 

Communication  initiation  shall  be  as  defined  in  3. 2. 3. 8. 

Detenni nation  as  to  which  device  has  control  of  the  line  at  aqy  particular 
instant  is  a  function  of  the  control  character  handshaking  process  and  DCU 
initialized  state.  (Reference  functional  flowcharts.) 

3. 2. 3. 6  Special  Cases 

3. 2.3 .6.1  No  Data  to  Send 

nr...  DCU,  it  simply  responds  to 

the  DCU  s  ENQ  with  the  normal  RVI  to  turn  the  communication  line  around  and 
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sends  a  header  with  a  zero  block  count.  If  a  DCU  is  emotv  it  resoond^i  +n  ;» 

code^^efl°eJtinr®"Vj^\®  containing  a  zero  block  count  aSd  a  fault 

code  reflecting  no  data  to  send. 

3. 2. 3. 7  Timeout  Control 

If  communications  are  lost  for  a  period  of  500  milliseconds,  at  any 
time,  a  timeout  condition  shall  be  declared;  communication  lines  shall  be 
returned  to  logic  high  or  spacing  conditions  and  startup  shall  be  attempted 

as  described  in  paragraphs  3. 1.2. 1.3  and  3.2.3.8  before  declaring  a  com¬ 
munications  fault.  '•  a  a  '-w'l 

3. 2. 3. 8  Startup  Control 

^  initiate  communications  by  delaying  at  least  1  second 
after  application  of  power  to  the  interface,  followed  by  repeated 
transmission  of  the  ENQ  control  character  for  2  seconds  at  50  millisecond 
intervals,  or  until  an  affirmative  acknowledgement  is  received  by  the  DCU 
The  equipment  receiving  the  ENQ  shall  respond  with  an  affirmative 

and  functiorT”^  control  character  depending  on  the  desired  line  direction 

3 >2 »4  Communications  Botween  Devices 

The  flowcharts  referenced  by  the  following  paragraphs  are  intended  to 
depict  information  flow,  state  transitions,  and  liSe  contfol  iU  a  Somal 

functional  flowcharts  and  are  not  intended  to 
depict  the  software  structure  to  achieve  implementation. 

3«2.4.1  ADR/DCU  Communci ations 

tnainr  f.mlf f between  these  devices  shall  be  limited  to  three 
major  functions.  They  are:  1)  downloading  of  ADR  accumulated  data,  2) 
uploading  of  data  to  the  ADR,  and  3)  function  requests. 

3 .2 .4.1 .1  ADR  to  DCU  Download 

is  estimated  to  constitute  the  major  operational 
useage  of  this  interface.  Once  the  physical  connection  has  been  made  and 

fiq™erAl’o"%l"l  transfer  shall  progress  as  illustrated  in 

figures  Al.O,  Al.l  and  Dl.O.  These  figures  are  referenced  in  the  following 

3. 2. 4. 1.1.1  Communications  Setup 

of  pn  run  interface  has  been  enabled  it  awaits  the  reception 

of  an  ENQ  control  character.  If  the  ADR  needs  to  perform  BIT  or  other 

prior  to  initiating  communications  it  enters  a  wait 

proceed  the  recorder 

3. 2. 4. 1.1. 2  DCU  Detemi nation 

a-u  communications  have  been  established  and  the  DCU  has 
received  the  expected  RVI  it  shall  respond  according  to  its  initialized 

state.  The  DCU  shall  be  initialized  by  either  the  GSC  or  its  own  keyboard 
to  perform  a  specific  function.  Neyooara 
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3.2»4«1.1 ,3  Data  Transfer 

u  4.  k  OCU  responds  with  an  ACK  to  allow  automatic  download  if  it 

has  not  been  initialized  to  perform  a  different  task.  When  the  ADR  recoqni- 
zes  this  ACK,  Al.O  (2),  it  enters  the  download  mode.  The  header  is  then 
transmitted  and  the  response  is  received  from  the  DCU.  This  response  could 
be  one  of  4  acknowledgements.  A  NAK  would  request  retransmission,  a  WACK 
would  hold  the  communications  and  either  an  RVI  or  ACK  would  transition 
control  from  the  transmit  header  mode  back  to  the  download  mode.  If  the 
response  is  RVI  at  this  point  the  DCU  has  aborted  transfer.  The  ADR 

reestablishment  of  communications.  If 
the  DCU  response  was  an  ACK  the  ADR  enters  a  transmit  text  mode.  Once  all 
data  has  been  transferred  the  DCU  acknowledges  the  last  block  with  an  RVI 
thus  reaming  control  to  the  DCU.  The  ADR  then  acknowledges  the  request’ 
and  awaits  reestablishment  of  communications. 


3. 2.4. 1.2 
and  Dl.l. 


DCU  to  ADR  Upload 

DCU  to  ADR  upload  procedures  are  depicted  in  Figures  Al.O,  Dl.O, 


3 .2 .4.1 .3  Application  Unique  Function  Requests 

Reference  figures  Al.O,  A1.3,  DAl.O,  and  DAI .3. 

3»2.4.2  DCU  to  GSC  Communications 

4.  performed  on  this  interface  shall  be  limited  to:  l) 

^  2)  initialization  of  the 

fSlicUoS"e?u™  ?"o?  ?he  MR^  "  of  the  OCU  to  perfonn  a 

3 .2 .4 .2 .1  DCU  to  GSC  Downl oad 

Reference  Figures  Gl.O  and  DGl.O. 

3.2. 4.2.2  GSC  to  DCU  Upload 

Reference  Figures  61.0  and  DGl.l. 

3 .2. 4. 2 .3  Function  Request  Initialization 
Reference  Figures  Gl.O  and  DGl.l. 

3»2.4.3  ADR  -  Subsystem  Communications 

To  be  supplied  (TBS)  when  applicable 

3»2.5  Control  Character  Definitions 

411  charactors  are  defined  in  the  paragraphs  that  follow. 

All  control  characters  are  transmitted  ASCII  encoded  as  defined  in  Table 
1  *1#  • 


3.2. 5.1  Start  of  Header  (SOH) 

implies,  this  control  character  identifies  the  data 
that  follows  as  header  information. 

3 .2 .5. 2  Start  of  Text  (STX) 

This  character  identifies  the  beginning  of  text  data. 
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3. 2. 5. 3  End  of  Transmission  Block  (ETB) 

....  identifies  the  end  of  a  transmitted  block  which  began  with  STX 
and  indicates  that  the  block  check  character  (BCC)  follows. 

3. 2. 5. 4  End  of  Text  (ETX) 


ETX  marks  the  end  of  a  block  which  started  with  either  SOH  or  STX. 
Its  function  IS  the  same  as  ETB  except  that  it  indicates  no  more  data  blocks 
to  send  in  the  case  of  STX. 


3.2.5. 5  Negative  Acknowledgement  (NAK) 

This  is  the  response  to  the  transmitting  device  that  the  last  block 
or  control  character  was  received  in  error  and  shall  be  retransmitted. 

3. 2. 5. 6  Enq ui ry  ( ENQ ) 

ENQ  is  used  to  establish  communications. 

3. 2. 5. 7  Affirmative  Acknowledgement  (ACK) 

This  control  character  verifies  to  the  sender  that  the  previous 
block  was  received  without  errors,  or  is  used  (when  applicable)  as  an  affir¬ 
mative  acknowledgement  of  a  correctly  received  control  character. 

Wait  Before  Transmit  Positive  Acknowledgement  (WACK) 

A  WACK  response  from  the  receiving  device  is  an  affirmative 
acknwledgement  of  a  block,  and  indicates  the  receiver  is  not  ready  to 
receive  the  next  block.  The  transmitting  device  sends  ACK  and  the  receiver 
responds  with  WACK  at  least  once  every  450  milliseconds  (to  prevent  a  time- 
out  condition  as  described  in  paragraph  3. 2 .3. 7)  until  ready  to  receive  the 
next  block.  When  the  receiver  is  ready,  it  responds  with  an  ACK. 

3. 2. 5.9  Reverse  Interrupt  (RVI) 

An  RVI  is  an  affirmative  acknowledgement.  It  requests  the 
transmitting  device  to  assume  the  role  of  receiver  and  thus  turn  the  com¬ 
munication  line  around. 


3.2.5.10  Temporary  Text  Delay  (TTD) 

This  control  character  is  sent  by  the  transmitting  device  when  it 
Is  but  wants  to  retain  the  line.  The  receiver  responds  with  ACK 

to  each  TTD  sent  until  the  transmitter  is  ready.  The  transmitter  shall  send 

a  TTD  control  character  at  least  once  every  450  milliseconds  to  retain  the 
line. 


3.2.5.11  Data  Delimiters  (DCl.  DC2,  DC3,  DC4,  FS) 

The  codes  for  the  5  data  delimiters  are  defined  in  Table  1.0. 
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CONTROL  CHARACTER  CODE  ASSIGNMENTS 


CONTROL  CHARACTER  OCTAL  HEXIDECIMAL 


SOH 

001 

01 

STX 

002 

02 

ETX 

003 

03 

ENQ 

005 

05 

ACK 

006 

06 

DCl 

021 

11 

0C2 

022 

12 

DC3 

023 

13 

DC4 

024 

14 

NAK 

025 

15 

ETB 

027 

'17 

FS 

034 

1C 

HACK 

035 

ID 

RVI 

036 

IE 

TTD 

037 

IF 

DECIMAL 

1 


TABLE  1.0 
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CA>oaroror>ororoi-AH->H-* 

►-•ovoootUH-ovooo'-ao^cncjro 


ASCII  DISPLAY  CHARAnTFR<; 


CHARACTER 


HEXIDECIMAL 


null 

000 

CR 

015 

space 

040 

042 

$ 

044 

% 

045 

& 

1 

046 

• 

047 

( 

050 

) 

051 

★ 

052 

+ 

053 

» 

054 

II 

055 

056 

/ 

057 

0 

060 

1 

061 

2 

062 

3 

063 

4 

064 

5 

065 

6 

066 

7 

067 

8 

070 

9 

071 

< 

074 

075 

> 

076 

077 

0 

100 

A 

101 

B 

102 

C 

103 

D 

104 

E 

105 

F 

106 

G 

107 

H 

110 

I 

111 

J 

112 

K 

113 

L 

114 

M 

115 

N 

116 

0 

117 

00 

OC 

20 

22 

24 

25 

26 

27 

28 
29^ 
2A 
2B 
2C 
2D 
2E 
2F 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 
3C 
3D 
3E 
3F 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 
4A 
4B 
4C 
40 
4E 
4F 


DECIMAL 


0 

12 

32 

34 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 
60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 


-15- 


p 

120 

50 

Q 

121 

51 

R 

122 

52 

S 

123 

53 

T 

124 

54 

U 

125 

55 

V 

126 

56 

W 

127 

57 

X 

130 

58 

Y 

131 

59 

Z 

132 

5A 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 


TABLE  2.0 


-16- 


ASCII  CODES  (1968) 


DEFINITION 


HEXIDECIMAL 


DECIMAL 


NUL 

SON 

STX 

ETX 

EOT 

ENQ 

ACK 

BEL 

BS 

HT 

LF 

VT 

FF 

CR 

50 

51 
DLE 
DCl 
DC2 
DCS 
DC4 
NAK 
SYN 
ETB 
CAN 
EM 
SUB 
ESC 
FS 
GS 
RS 
US 
SP 


j 

II 


# 

$ 

% 

& 

t 

( 

) 

* 

+ 


/ 


000 

001 

002 

003 

004 

005 

006 

007 

010 

Oil 

012 

013 

014 

015 

016 

017 

020 

021 

022 

023 

024 

025 

026 

027 

030 

031 

032 

033 

034 

035 

036 

037 

040 

041 

042 

043 

044 

045 

046 

047 

050 

051 

052 

053 

054 

055 

056 

057 


00 

01 

02 

03 

04 

05 

06 

07 

08 

09 

OA 

OB' 

OC 

OD 

OE 

OF 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 
lA 
IB 
1C 
ID 
IE 
IF 

20 
21 
22 

23 

24 

25 

26 

27 

28 
29 
2A 
2B 
2C 
2D 
2E 
2F 


10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 


-17- 


0 

1 

2 

3 

4 

5 

6 

7 

8 
9 


t 


< 


> 


? 

0 

A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 

0 

P 


Q 

R 

S 

T 

U 

Y 
W 
X 

Y 
Z 
[ 

\ 

] 

A 


\ 

a 

b 

c 


060 

061 

062 

063 

064 

065 

066 

067 

070 

071 

072 

073 

074 

075 

076 

077 

100 

101 

102 

103 

104 

105 

106 
107 
110 
111 
112 

113 

114 

115 

116 
117 
120 
121 
122 

123 

124 

125 

126 
127 

130 

131 

132 

133 

134 

135 

136 

137 
140- 

141 

142 

143 


30 

31 

32 

33 

34 

35 

36 

37 

38 

39 
3A 
38 
3C 
3D 
3E 
3F 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 
4A 
48 
4C 
40 
4E 
4F 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 
5A 
58 
5C 
5D 
5E 
5F 

60 
61 
62 
63 


48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 


-18- 


d 

e 

f 

9 

h 

i 

j 

k 

1 

m 

n 

0 


DEL 


144 

64 

145 

65 

146 

66 

147 

67 

150 

68 

151 

69 

152 

6A 

153 

68 

154 

6C 

155 

6D 

156 

6E 

157 

6F 

160 

70 

161 

71 

162 

72 

163 

73 

164 

74 

165 

75 

166 

76 

167 

77 

170 

78 

171 

79 

172 

7A 

173 

7B 

174 

7C 

175 

7D 

176 

7E 

177 

7F 

100 

101 

102 

103 

104 

105 

106 

107 

108 
109 

no 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 
127 


TABLE  3.0 


-19- 


&fiOUA^X> 


'/6u/f/r  A/.o 


-  J7- 


Pf,  (  ^ s^ecjAL  ft^^cr/0^/  /^0OB 


TiffiMtmfr 

/?c/f 


nGl//?€  J)/.!  J  (coHriNveoS 


30  ~ 


f^irrun/^ 


fy.QtmiF  Q/.O  .  *'6SC  TV  "ben  Co/n/nu/^fi caT/ca^  <  *' 


-  ??- 


&J.I  &SC  To  'hcu  LoA'b 


&l,Z  6SC  To  J>c,u  ^o''b£' 

-  jr- 


TRUH^filtr 


FfQ>Uf{E  S7.0  BLOCK  H4Hb SH/tK E 


sc.e>  j  Atfipe 


3 


sv.o  .  ‘^T/tA^s/»ir  rjTxT  /na't>£‘ ** 


-  ZSr- 


jFA/Tjr^ 


/yta2>^» 


-  V<?  - 


A/orss 


U)  AtusT  6£'  t?/:  't>/ST/A/6uii>t^/^C.  esTh/^syu'  /^a/ 

COAJT/lOt.  (CC)  /A/u'A^t'h  STA^7~  o/r  ^ij>c/C  TO  AA/Oh/ 

TO  ••A/AK‘\ 

(i)  TA^"  'hen  TAAA^Anrs  Vn'tf"  ASA  ASAA6/tAfif^  UATJL  A  ^A^ih 

ASS  AC  ASS  tS  ASCS/nSh>, 

(3)  SA'nS  AS  C2) 

(^)  TAS'  AS/4h£A  ^OAhS^  /^TO  TAS"  hcU  SAO/*!  TAS  Qsc  SMA^^  CCA7>^/a/ 
/95C2r  SA/cohSh  fAA  AAAAOAAAA  3.2. a..  1.7 


